Мета інфологічне моделювання - забезпечення найбільш природних для людини способів збору та подання тієї інформації, яку передбачається зберігати в створюваній базі даних. Тому інфологічну модель даних намагаються будувати за аналогією з природною мовою (останній не може бути використаний у чистому вигляді через складність комп'ютерної обробки текстів і неоднозначності будь-якого природної мови). Основними конструктивними елементами инфологической моделей є сутності, зв'язки між ними і їх властивості (атрибути).
Сутність - будь-який помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в базі даних. Сутностями можуть бути люди, місця, літаки, рейси, смак, колір і т.д. Необхідно розрізняти такі поняття, як тип сутності й екземпляр сутності. Поняття тип сутності відноситься до набору однорідних особистостей, предметів, подій чи ідей, які виступають як ціле. Примірник сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром - Москва, Київ і т.д.
Атрибут - пойменована характеристика сутності. Його найменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДИМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, номерний знак, колір і т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато екземплярів чи значень:
Червоний, Синій, Банановий, Біла ніч і т.д.,
однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.
Абсолютна відмінність між типами сутностей і атрибутами відсутня. Атрибут є таким тільки в зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу колір - це тільки атрибут продукту виробництва, а для лакофарбової фабрики колір - тип сутності.
Ключ - мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Для сутності Розклад (п. 1.2) ключем є атрибут Номер_рейса або набір: Пункт_отправленія, Время_вилета і Пункт_назначенія (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).
Зв'язок - асоціювання двох або більше сутностей. Якби призначенням бази даних було тільки збереження окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простий. Однак одна з основних вимог до організації бази даних - це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А так як у реальних базах даних нерідко містяться сотні чи навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність инфологической моделей.
Характеристика зв'язків і мова моделюванняПри побудові инфологической моделей можна використовувати мову ER-діаграм (від англ. Entity-Relationship, тобто сутність-зв'язок). У них сутності зображуються позначеними прямокутниками, асоціації - позначеними ромбами чи шестикутниками, атрибути - позначеними овалами, а зв'язки між ними - ненаправленими ребрами, над якими може проставлятися ступінь зв'язку (1 чи буква, що заміняє слово "багато") і необхідне пояснення.
Між двома сутностей, наприклад, А і В можливі чотири види зв'язків.
Перший тип - зв'язок один-до-одного (1:1): у кожен момент часу кожному представнику (екземпляру) сутності А відповідає 1 чи 0 представників сутності В:
Студент може не "заробити" стипендію, одержати звичайну чи одну з підвищених стипендій.
Другий тип - зв'язок один-до-БАГАТЬОМ (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності В.
Квартира може пустувати, у ній може жити один чи кілька мешканців.
Так як між двома сутностями можливі зв'язки в обох напрямках, то існує ще два типи зв'язку багато-до-ОДНОМУ (М: 1) і БАГАТО-КО-БАГАТЬОМ (М: N).
Приклад 2.1. Якщо зв'язок між сутностями ЧОЛОВІКА і ЖІНКИ називається ШЛЮБ, то існує чотири возможнихпредставленія такого зв'язку:
Характер зв'язків між сутностями не обмежується перерахованими. Існують і більш складні зв'язки:
безліч зв'язків між одними і тими ж сутностями(Пацієнт, маючи одного лікуючого лікаря, може мати також кілька лікарів-консультантів; лікар може бути лікуючим лікарем декількох пацієнтів і може одночасно консультувати кілька інших пацієнтів);
тренарние зв'язку(Лікар може призначити кілька пацієнтів на кілька аналізів, аналіз може бути призначений декількома лікарями декільком пацієнтам і пацієнт може бути призначений на кілька аналізів декількома лікарями);
зв'язку більш високих порядків, семантика (зміст) яких іноді дуже складна.У наведених прикладах для підвищення ілюстративності розглянутих зв'язків не показані атрибути сутностей і асоціацій у всіх ER-діаграмах. Так, введення лише кількох основних атрибутів в опис шлюбних зв'язків значно ускладнить ER-діаграму (мал. 2.1, а). У зв'язку з цим мова ER-діаграм використовується для побудові невеликих моделей і ілюстрації окремих фрагментів великих. Частіше ж застосовується менш наочний, але більш змістовний мова інфологічне моделювання (ЯІМ), в якому сутності й асоціації представляються пропозиціями виду:
СУТНІСТЬ (атрибут 1, атрибут 2, ..., атрибут n) АСОЦІАЦІЯ [СУТНІСТЬ S1, СУТНІСТЬ S2, ...] (атрибут 1, атрибут 2, ..., атрибут n)де S - ступінь зв'язку, а атрибути, що входять у ключ, повинні бути відзначені за допомогою підкреслення.
Так, розглянутий вище приклад безлічі зв'язків між сутностями, може бути описаний на ЯІМ наступним чином:
Лікар (Номер_врача, Прізвище, Ім'я, По батькові, Спеціальність) Пацієнт (Регістраціонний_номер, Номер ліжка, Прізвище, Ім'я, По батькові, Адреса, Дата народження, Пол) Лечащій_врач [Лікар 1, Пацієнт M] (Номер_врача, Регістраціонний_номер) Консультант [Лікар M, Пацієнт N] (Номер_врача, Регістраціонний_номер).Рис. 2.1. Приклади ER-діаграм
Для виявлення зв'язків між сутностями необхідно, як мінімум, визначити самі сутності. Але це не просте завдання, оскільки в різних предметних областях один і той самий об'єкт може бути сутністю, атрибутом або асоціацією. Проілюструємо таке твердження на прикладах, пов'язаних з описом шлюбних зв'язків (див. приклад 2.1).
Приклад 2.2. Відділ записів актів громадянського стану (РАГС) має справу не з усіма людьми, а тільки з тими, хто звернувся з проханням про реєстрацію шлюбу, народження або смерті. Тому в країнах, де допускаються лише традиційні шлюби, відділи РАЦС можуть розміщувати відомості про реєстрованих шлюбах в єдиній сутності:
Шлюб (Номер_свідетельства, Фамілія_мужа, Імя_мужа, Отчество_мужа, Дата_рожденія_мужа, Фамілія_жени, ..., Дата_регістраціі, Место_регістраціі, ...),ER-діаграма якої наведено на рис. 2.1, б.
Приклад 2.3. Тепер розглянемо ситуацію, коли відділ РАГС розташований в країні, що допускає багатоженство. Якщо для реєстрації шлюбів використовувати сутність "Шлюб" прикладу 2.2, то будуть дублюватися відомості про чоловіків, що мають кілька дружин (див. табл. 2.1).
Таблиця 2.1
| Номер свідоцтва | Прізвище чоловіка | ... | Прізвище дружини | ... | Дата реєстрації |
| 1-ЮБ 154745 | Пєтухов | ... | Курочкіна | ... | 06/03/1991 |
| 1-ЮБ 163489 | Пєтухов | ... | Пеструшкіна | ... | 11/08/1991 |
| 1-ЮБ 169887 | Пєтухов | ... | Рябова | ... | 12/12/1992 |
| 1-ЮБ 169878 | Селезньов | ... | Уточкіна | ... | 12/12/1992 |
| 1-ЮБ 154746 | Парасюк | ... | Свінюшкіна | ... | 06/03/1991 |
| 1-ЮБ 169879 | Парасюк | ... | Льоха | ... | 12/12/1992 |
| ... | ... | ... | ... | ... | ... |
Дублювання можна виключити створенням додаткової сутності "Чоловіки"
Чоловіки (Код_М, Прізвище, Ім'я, По батькові, Дата народження, Місце народження)і заміною сутності "Шлюб" характеристикою (див. п. 2.3) з посиланням на відповідне опис по суті "Чоловіки".
Шлюб (Номер свідоцтва, Код_М, Прізвище дружини, ..., Дата реєстрації, ...){ Чоловіки}.ER-діаграма зв'язку цих сутностей показана на рис. 2.1, в, а приклад їх примірників у табл. 2.2 та 2.3.
Таблиця 2.2
| Код_М | Прізвище | Ім'я | По батькові | Рік / р. | Місце народж. |
| 111 | Пєтухов | Альфред | Остапович | 1971 | р. Цапелька |
| 112 | Селезньов | Вавила | Абрамович | 1973 | м. Гусєв |
| 113 | Парасюк | Горацій | Федуловіч | 1972 | р. Свіньїн |
| ... | ... | ... | ... | ... | ... |
Таблиця 2.3
| Номер свідоцтва | Код_М | Прізвище дружини | Ім'я дружини | Дата реєстрації | ... |
| 1-ЮБ 154745 | 111 | Курочкіна | Августина | 06/03/1991 | ... |
| 1-ЮБ 163489 | 111 | Пеструшкіна | Маріана | 11/08/1991 | ... |
| 1-ЮБ 169877 | 111 | Рябова | Мілана | 12/12/1992 | ... |
| 1-ЮБ 169878 | 112 | Уточкіна | Вероніка | 12/12/1992 | ... |
| 1-ЮБ 154746 | 113 | Свінюшкіна | Ельвіра | 06/03/1991 | ... |
| 1_ЮБ 169879 | 113 | Льоха | Руфіна | 12/12/1992 | ... |
| ... | ... | ... | ... | ... | ... |
Приклад 2.4. Нарешті, розглянемо випадок, коли який-небудь організації потрібні були дані про наявність у ній сімейних пар, а для зберігання відомостей про співробітників вже є сутність
Співробітники (Табельний_номер, Прізвище, Ім'я, ...).Використання, розглянутої у прикладі 2.2, сутності "Шлюб" недоцільно: у "Співробітники" вже є прізвища, імена, по батькові подружжя. Тому створимо асоціацію
Шлюб [Співробітник 1, Співробітник 1] (Табельний_номер_мужа, Табельний_номер_жени, ...),зв'язує між собою певні екземпляри сутності "Співробітники" (рис. 2.1, г).
На закінчення відзначимо, що ER-діаграма рис. 2.1, а описує структуру розміщення даних про шлюби у відділах ЗАГС країн, що допускають групові шлюби, а ER-діаграми прикладу 2.1, опису будь-яких видів шлюбів в організаціях, де є сутності "чоловіка" і "жінки", що включають неодружених і незаміжніх.
Що ж таке "зв'язок"? У ER-діаграмах це лінія, що з'єднує геометричні фігури, що зображують сутності, атрибути, асоціації та інші інформаційні об'єкти. У тексті ж цей термін використовується для вказівки на взаємозалежність сутностей. Якщо ця взаємозалежність має атрибути, то вона називається асоціацією.
Класифікація сутностейНастав момент розібратися в термінології. К. Дейт [3] визначає три основні класу сутностей: стрижневі, асоціативні і характеристичні, а також підклас асоціативних сутностей - позначення.
Стрижнева сутність (стрижень) - це незалежна сутність (трохи докладніше вона буде визначена нижче).
У розглянутих раніше прикладах стрижні - це "Студент", "Квартира", "Чоловіки", "Лікар", "Шлюб" (з прикладу 2.2) та інші, назви яких поміщені в прямокутники.
Асоціативна сутність (асоціація) - це зв'язок виду "багато-до-багатьох" ("-до-багатьох" і т.д.) між двома або більше сутностями або екземплярами сутності (як у прикладі 2.4). Асоціації розглядаються як повноправні сутності:
вони можуть брати участь в інших асоціаціях і позначеннях точно так само, як стрижневі сутності;
можуть мати властивості, тобто мати не тільки набір ключових атрибутів, необхідних для вказівки зв'язків, але і будь-яке число інших атрибутів, що характеризують зв'язок. Наприклад, асоціації "Шлюб" з прикладів 2.1 і 2.4 містять ключові атрибути "Код_М", "Код_Ж" і "Табельний номер чоловіка", "Табельний номер дружини", а також уточнюючі атрибути "Номер свідоцтва", "Дата реєстрації", "Место_регістраціі "," Номер запису до книги ЗАГС "і т.д.
Характеристична сутність (характеристика) - це зв'язок виду "багато-до-одного" або "одна-до-одного" між двома сутностями (приватний випадок асоціації). Єдина мета характеристики в рамках розглянутої предметної області складається в описі або уточнення деякої іншої сутності. Необхідність в них виникає у зв'язку з тим, що сутності реального світу мають іноді багатозначні властивості. Чоловік може мати кілька дружин (приклад 2.3), книга - кілька характеристик перевидання (виправлене, доповнене, перероблене, ...) і т.д.
Існування характеристики повністю залежить від характеризується сутності: жінки позбавляються статусу дружин, якщо вмирає їх чоловік.
Для опису характеристики використовується нова пропозиція ЯІМ, що має в загальному випадку вигляд:
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, ...) {СПИСОК ХАРАКТЕРИЗУЮТЬСЯ СУТНІСТЬ}.Розширимо також мову ER-діаграм, ввівши для зображення характеристики трапецію (рис. 2.2).
Рис. 2.2. Елементи розширеної мови ER-діаграм
Позначає сутність або позначення - це зв'язок виду "багато-до-одного" або "одна-до-одного" між двома сутностями і відрізняється від характеристики тим, що не залежить від позначається сутності.
Розглянемо приклад, пов'язаний із зарахуванням співробітників у різні відділи організації.
При відсутності жорстких правил (співробітник може одночасно зараховуватися в кілька відділів або не зараховуватимуться ні в один відділ) необхідно створити опис з асоціацією Зарахування:
Відділи (Номер відділу, Назва відділу, ...) Службовці (Табельний номер, Прізвище, ...) Зарахування [Відділи M, Службовці N] (Номер відділу, Табельний номер, Дата зарахування).Однак, за умови, що кожен із співробітників повинен бути обов'язково зарахований в один з відділів, можна створити опис з позначенням Службовці:
Відділи (Номер відділу, Назва відділу, ...) Службовці (Табельний номер, Прізвище, ..., Номер відділу, Дата зарахування) [Відділи]У даному прикладі службовці мають незалежне існування (якщо видаляється відділ, то з цього не випливає, що також повинні бути видалені службовці такого відділу). Тому вони не можуть бути характеристиками відділів і названі позначеннями.
Позначення використовують для зберігання повторюваних значень великих текстових атрибутів: "кодифікатори" вивчаються студентами дисциплін, найменувань організацій та їх відділів, переліків товарів і т.п.
Опис позначення зовні відрізняється від опису характеристики тільки тим, що позначаються сутності полягає не в фігурні дужки, а в квадратні:
ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, ...)[ СПИСОК ПОЗНАЧАЄТЬСЯ СУТНОСТІ].Як правило, позначення не розглядаються як повноправні суті, хоча це не привело б до якої-небудь помилку.
Позначення і характеристики не є повністю незалежними сутностями, оскільки вони передбачають наявність деякої іншої сутності, яка буде "позначатися" або "характеризуватися". Проте вони все ж представляють собою окремі випадки сутності і можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (більш низького рівня) характеристики. Підкреслимо також, що всі екземпляри характеристики повинні бути обов'язково пов'язані з яким-небудь примірником характеризується сутності. Однак допускається, щоб деякі екземпляри характеризується суті не мали зв'язків. Правда, якщо це стосується шлюбів, то сутність "Чоловіки" повинна бути замінена на сутність "Чоловіки" (немає чоловіка без дружини).
Перевизначивши тепер стрижневу сутність як сутність, яка не є ні асоціацією, ні позначенням, ні характеристикою. Такі сутності мають незалежне існування, хоча вони і можуть позначати інші сутності, як, наприклад, співробітники позначають відділи.
На закінчення розглянемо приклад побудови инфологической моделі бази даних "Харчування", де повинна зберігатися інформація про страви (рис. 2.3), їх щоденному споживанні, продуктах, з яких готуються ці страви, і постачальників цих продуктів. Інформація буде використовуватися кухарем і керівником невеликого підприємства громадського харчування, а також його відвідувачами.
| 1. Лобіо по грузинськи Ламану очищену квасоля, нашатковану цибулю посолити, посипати перцем і припустити в маслі з невеликою кількістю бульйону; додати кинзу, зелень петрушки, Рейган (базилік) і довести до готовності. Потім запекти в духовці. Квасоля стручкова (свіжа або консервована) 200, Цибуля зелена 40, Масло вершкове 30, Зелень 10. Вихід 210. Калорій 725. |
Рис. 2.3. Приклад кулінарного рецепта
За допомогою зазначених користувачів виділені наступні об'єкти і характеристики проектованої бази:
Страви, для опису яких потрібні дані, що входять до їх кулінарні рецепти: номер страви (наприклад, з книги кулінарних рецептів), назву страви, вигляд страви (закуска, суп, гаряче і т.п.), рецепт (технологія приготування страви), вихід (вага порції), назва, калорійність і вага кожного продукту, що входить в блюдо. Для кожного постачальника продуктів: найменування, адресу, назву поставленого продукту, дата поставки і ціна на момент поставки. Щоденне споживання страв (витрата): блюдо, кількість порцій, дата.Аналіз об'єктів дозволяє виділити:
стрижні Страви, Продукти і Міста; асоціації Склад (пов'язує Страви з Продуктами) іПоставки (пов'язує Постачальників з Продуктами);
позначення Постачальники; характеристики Рецепти і Витрата.ER-діаграма моделі показана на рис. 2.4. а модель мовою ЯІМ має наступний вигляд:
Страви (БЛ, Страва, Вигляд) Продукти (ПР, Продукт, Калорійність) Постачальники (ПОС, Місто, Постачальник) [Місто] Склад [Страви M, Продукти N] (БЛ, ПР, Вага (г)) Постачання [Постачальники M, Продукти N] (ПОС, ПР, Дата_П, Ціна, Вага (кг)) Міста (Місто, Країна) Рецепти (БЛ, Рецепт) {Страви} Витрата (БЛ, Дата_Р, Порцій) {Страви}У цих моделях Страва, продукт та Постачальник - найменування, а БЛ, ПР і ПОС - цифрові коди страв, продуктів і організацій, що постачають ці продукти.
Рис. 2.4. Инфологическая модель бази даних "Харчування"
Про первинних і зовнішніх ключахНагадаємо, що ключ або можливий ключ - це мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Кожна сутність має хоча б одним можливим ключем. Один з них приймається за первинний ключ. При виборі первинного ключа слід віддавати перевагу несоставним ключам або ключам, складеним з мінімального числа атрибутів. Недоцільно також використовувати ключі з довгими текстовими значеннями (краще використовувати цілочисельні атрибути). Так, для ідентифікації студента можна використовувати або унікальний номер залікової книжки, або набір із прізвища, імені, по батькові, номери групи і може бути додаткових атрибутів, так як не виключена поява в групі двох студентів (а частіше студенток) з однаковими прізвищами, іменами та по батькові. Погано також використовувати в якості ключа не номер страви, а його назва, наприклад, "Закуска з плавлених сирків" Дружба "з шинкою і солоним огірком" або "Заєць в сметані з картопляними крокетами і салатом з червоної капусти".
Не допускається, щоб первинний ключ стрижневою сутності (будь-який атрибут, який бере участь в первинному ключі) брав невизначене значення. Інакше виникне суперечлива ситуація: з'явиться не володіє індивідуальністю, і, отже не існуючий примірник стрижневою сутності. З тих же причин необхідно забезпечити унікальність первинного ключа.
Тепер про зовнішні ключах:
Якщо сутність З пов'язує сутності А і В, то вона повинна включати зовнішні ключі, відповідні первинним ключам сутностей А і В. Якщо сутність В означає сутність А, то вона повинна включати зовнішній ключ, відповідний первинному ключу сутності А.У п. 2.3 розглядався приклад, де "Службовці" позначали "Відділи" і включали зовнішній ключ "Номер відділу", відповідний первинному ключу сутності "Відділи".
Зв'язок між первинними і зовнішніми ключами сутностей ілюструється рис. 2.5.
Рис. 2.5. Структури: а - асоціації; б - позначення (характеристики)
Тут для позначення будь-якої з асоційованих сутностей (стрижнів, характеристик, позначень або навіть асоціацій) використовується новий узагальнюючий термін "Мета" або "Цільова сутність".
Таким чином, при розгляді проблеми вибору способу представлення асоціацій і позначень у базі даних основне питання, на який слід отримати відповідь: "Які зовнішні ключі?". І далі, для кожного зовнішнього ключа необхідно вирішити три питання:
1. Чи може цей зовнішній ключ приймати невизначені значення (NULL-значення)? Інакше кажучи, чи може існувати певний екземпляр сутності даного типу, для якого невідома цільова сутність, що вказується зовнішнім ключем? У разі поставок це, ймовірно, неможливо - поставка, здійснювана невідомим постачальником, або постачання невідомого продукту не мають сенсу. Але у випадку з співробітниками така ситуація проте могла б мати сенс - цілком можливо, що який-небудь співробітник в даний момент не зарахований взагалі ні в який відділ. Зауважимо, що відповідь на це питання не залежить від примхи проектувальника бази даних, а визначається фактичним чином дій, прийнятим в тій частині реального світу, яка повинна бути представлена в даній базі даних. Подібні зауваження мають відношення і до питань, обговорюваних нижче.
2. Що має статися при спробі ВИДАЛЕННЯ цільової сутності, на яку посилається зовнішній ключ? Наприклад, при видаленні постачальника, який здійснив принаймні одну поставку. Існує три можливості:
| КАСКАДІРУЕТСЯ | Операція видалення "каскадіруется" з тим, щоб видалити також поставки цього постачальника. |
| ОБМЕЖУЄТЬСЯ | Видаляються лише ті постачальники, які ще не здійснювали поставок. Інакше операція видалення відкидається. |
| ВСТАНОВЛЮЄТЬСЯ | Для всіх поставок видаляється постачальника NULL-значення зовнішній ключ встановлюється в невизначене значення, а потім цей постачальник видаляється. Така можливість, звичайно, не застосовується, якщо даний зовнішній ключ не повинен містити NULL-значень. |
3. Що повинно відбуватися при спробі ОНОВЛЕННЯ первинного ключа цільової сутності, на яку посилається деякий зовнішній ключ? Наприклад, може бути зроблена спроба оновити номер такого постачальника, для якого є принаймні одна відповідна поставка. Цей випадок для визначеності знову розглянемо докладніше. Є ті ж три можливості, як і при видаленні:
| КАСКАДІРУЕТСЯ | Операція оновлення "каскадіруется" з тим, щоб оновити також і зовнішній ключ впоставках цього постачальника. |
| ОБМЕЖУЄТЬСЯ | Оновлюються первинні ключі лише тих постачальників, які ще не здійснювали поставок. Інакше операція оновлення відкидається. |
| ВСТАНОВЛЮЄТЬСЯ | Для всіх поставок такого постачальника NULL-значення зовнішній ключ встановлюється в невизначене значення, а потім оновлюється первинний ключ постачальника. Така можливість, звичайно, не застосовується, якщо даний зовнішній ключ не повинен містити NULL-значень. |
Таким чином, для кожного зовнішнього ключа в проекті проектувальник бази даних повинен специфікувати не тільки поле або комбінацію полів, що складають цей зовнішній ключ, і цільову таблицю, яка ідентифікується цим ключем, але також і відповіді на зазначені вище питання (три обмеження, які відносяться до цього зовнішнього ключа).
Нарешті, про характеристики - позначають сутності, існування яких залежить від типу позначаються сутностей. Позначення представляється зовнішнім ключем у таблиці, що відповідає цій характеристиці. Але три розглянуті вище обмеження на зовнішній ключ для даного випадку повинні специфікувати наступним чином:
NULL-значення не допустімиУДАЛЕНІЕ ІЗ (мета) КАСКАДІРУЕТСЯОБНОВЛЕНІЕ (первинний ключ мети) КАСКАДІРУЕТСЯЗазначені специфікації представляють залежність по існуванню характеристичних сутностей.
Обмеження цілісностіЦілісність (від англ. Integrity - незайманість, недоторканність, збереження, цілісність) - розуміється як правильність даних у будь-який момент часу. Але ця мета може бути досягнута лише у певних межах: СУБД не може контролювати правильність кожного окремого значення, що вводиться в базу даних (хоча кожне значення можна перевірити на правдоподібність). Наприклад, не можна виявити, що вводиться значення 5 (представляє номер дня тижня) насправді має дорівнювати 3. З іншого боку, значення 9 явно буде помилковим і СУБД повинна його відхилити. Однак для цього їй слід повідомити, що номери днів тижня повинні належати набору (1,2,3,4,5,6,7).
Підтримка цілісності бази даних може розглядатися як захист даних від невірних змін або руйнувань (не плутати з незаконними змінами і руйнуваннями, які є проблемою безпеки). Сучасні СУБД мають ряд засобів для забезпечення підтримання цілісності (так само, як і засобів забезпечення підтримання безпеки).
Виділяють три групи правил цілісності:
Цілісність за сутностей. Цілісність по посиланнях. Цілісність, обумовлена користувачем.У п. 2.4 була розглянута мотивування двох правил цілісності, загальних для будь-яких реляційних баз даних.
Не допускається, щоб будь-якої атрибут, який бере участь в первинному ключі, брав невизначене значення. Значення зовнішнього ключа повинне або: бути рівним значенням первинного ключа мети; бути повністю невизначеним, тобто кожне значення атрибута, що бере участь у зовнішньому ключі повинно бути невизначеним. Для будь-якої конкретної бази даних існує ряд додаткових специфічних правил, які відносяться до неї однією і визначаються розробником. Найчастіше контролюється: унікальність тих чи інших атрибутів,
діапазон значень (екзаменаційна оцінка від 2 до 5),
приналежність набору значень (стать "М" або "Ж").
Читач, що познайомився лише з матеріалом даної і попередньої глав, не зможе правильно сприйняти і оцінити тих порад і рекомендацій з побудови хорошою инфологической моделі, які десятиліттями формувалися найбільшими фахівцями в області обробки даних. Для цього треба, принаймні, вивчити наступні матеріали. В ідеалі ж необхідно, щоб читач попередньо реалізував хоча б один проект інформаційної системи, запропонував його реальним користувачам і побув адміністратором бази даних та програм настільки довго, щоб усвідомити хоча б невелику дещицю проблем, що виникають із-за недостатньо продуманого проекту. Досвід автора і всіх знайомих йому фахівців з інформаційних систем показує, що будь-які теоретичні рекомендації сприймаються всерйоз лише після кількох безрезультатних спроб пожвавлення невдало спроектованих систем. (Хоча є й такі проектувальники, які продовжують вірити, що зможуть реанімувати вмираючий проект за допомогою зміни програм, а не инфологической моделі бази даних.)
Основна складність сприйняття рекомендацій, наведених у четвертому розділі та додатку Б, чисто психологічного плану.
Дійсно, для визначення переліку та структури даних, що зберігаються треба зібрати інформацію про реальних і потенційних додатках, а також про користувачів бази даних, а при побудові инфологической моделі слід дбати лише про надійність зберігання цих даних, геть забуваючи про додатки і користувачів, для яких створюється база даних.
Це пов'язано з абсолютно відрізняються вимогами до бази даних прикладних програмістів та адміністратора бази даних. Перші хотіли б мати в одному місці (наприклад, в одній таблиці) всі дані, необхідні їм для реалізації запиту з прикладної програми або з терміналу. Другі ж піклуються про виключення можливих спотворень даних, що зберігаються при введенні в базу даних нової інформації та оновлення або видалення існуючої. Для цього вони видаляють з бази даних дублікати і небажані функціональні зв'язки між атрибутами, розбиваючи базу даних на безліч маленьких таблиць (див. п. 4.6). Так як багаторічний світовий досвід використання інформаційних систем, побудованих на основі баз даних, показує, що недоліки проекту неможливо усунути будь-якими хитрощами в програмах додатків, то досвідчені проектувальники не дозволяють собі йти назустріч прикладним програмістам (навіть тоді, коли вони самі є такими).
І хоча автор усвідомлює, що більшість людей вважає за краще вчитися на власних помилках, він все ж таки ще раз радить недосвідченим проектувальникам баз даних:
чітко розмежовувати такі поняття як запит на дані і ведення даних (введення, редагування та видалення); пам'ятати, що, як правило, база даних є інформаційною основою не одного, а кількох додатків, частина з яких з'явиться в майбутньому; поганий проект бази даних не може бути виправлений за допомогою будь-яких (навіть найвитонченіших) додатків. ЛІТЕРАТУРА Атре Ш. Структурний підхід до організації баз даних. - М.: Фінанси і статистика, 1983. - 320 с. Бойко В.В., Савінков В.М. Проектування баз даних інформаційних систем. - М.: Фінанси і статистика, 1989. - 351 с. Дейт К. Посібник з реляційної СУБД DB2. - М.: Фінанси і статистика, 1988. - 320 с. Джексон Г. Проектування реляційних баз даних для використання з мікроЕОМ. -М.: Світ, 1991. - 252 с. Кирилов В.В. Структурізованние мову запитів (SQL). - СПб.: ІТМО, 1994. - 80 с. Мартін Дж. Планування розвитку автоматизованих систем. - М.: Фінанси і статистика, 1984. - 196 с. Мейєр М. Теорія реляційних баз даних. - М.: Світ, 1987. - 608 с. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., - М.: Світ, 1985. Кн. 1. - 287 с.: Кн. 2. - 320 с. Ульман Дж. Бази даних на Паскалі. - М.: Машинобудування, 1990. - 386 с. Хаббард Дж. Автоматизоване проектування баз даних. - М.: Світ, 1984. - 294 с. Цікрітізіс Д., лохівський Ф. Моделі даних. - М.: Фінанси і статистика, 1985. - 344 с.